What about user's password? I believe Asoka was asking something that would enable user to access CernVM using his/her CERN username / password (a la cern-config-users)... Did I misunderstood?
G.

On Oct 14, 2013, at 11:27 AM, Ioannis Charalampidis <[email protected]mailto:[email protected]> wrote:

You can merge this Pull Request by running

git pull https://github.com/wavesoft/cernvm-online master

Or view, comment on, or merge it at:

#1

Commit Summary

• Using logged-in username as default on new accounts

File Changes

• M src/cvmo/context/templates/pages/context.htmlhttps://github.com/Using logged-in username as default on new accounts #1/files#diff-0 (2)

Patch Links:

• https://github.com/cernvm/cernvm-online/pull/1.patch
• https://github.com/cernvm/cernvm-online/pull/1.diff

I think about the password we cannot and we shouldn't do anything. We don't see the password as it is handled by Shibboleth.

Thanks for the commit, Ioannis! For published contexts, it would be nice to have a templated user name that resolves to the logged in user name once the context gets cloned into the dashboard.

For sure, it would be impossible to do something in CernVM Online. Would it be possible though to use, inside the VM, CERN LDAP instead?

That would also add a new wow-effect-feature (:p), I spawn a VM (without having to edit or clone the context) [using WebAPI] and I can login with my CERN account...

On Oct 14, 2013, at 12:06 PM, jblomer [email protected] wrote:

I think about the password we cannot and we shouldn't do anything. We don't see the password as it is handled by Shibboleth.

—
Reply to this email directly or view it on GitHub.

The only way to allow CERN log-ins is to enable kerberos authentication and set-up the appropriate configuration for the CERN domain. Then we can sync the CERN users the user has specified.

This however has to be another module on amiconfig, or it should be a part of the boot process.

Regarding the templated username, I think it's a bit of an overkill... I think that a simpler alternative is to include an exta environment variable, for example 'CONTEXT_USER' that will contain the name of the user created the given context. An additional variable 'PAIR_USER' could be the user that paired the VM. (Those two usernames are different only on contexts on the marketplace)

The VM can then re-configure parts of it based on the contents of these variables.